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This Technical Specification (TS) has been produced by the ETSI 3 Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities or GSM identities. 
These should be interpreted as being references to the corresponding ETSI deliverables. The mapping of document 
identities is as follows: 

For 3GPP documents: 

3G TS I TR nn.nnn "<title>" (with or without the prefix 3G) 

is equivalent to 

ETSI TS I TR Inn nnn "[Digital cellular telecommunications system (Phase 2+) (GSM);] Universal Mobile 
Telecommunications System; <title> 

For GSM document identities of type "GSM xx.yy", e.g. GSM 01.04, the corresponding ETSI document identity may be 
found in the Cross Reference List on www.etsi.org/kev 
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Foreword 

This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document provides the description of the Packet Data Convergence Protocol (PDCP). 
PDCP provides its services to the NAS at the UE or the relay at the Radio Network Controller (RNC). 
PDCP uses the services provided by the Radio Link Control (RLC) sublayer. 
The main functions of PDCP are: 

Compression of redundant Network PDU control information (header compression). 

Transfer of packet data protocol user data using services provided by RLC protocol. 

The following function is not part of release '99 but will be included in Release 2000: 
Multiplexing of different RBs onto the same RLC -entity. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] 3G TS 25.401: "UTRAN Overall Description " 

[2] 3G TR 25.990: "Vocabulary for the UTRAN" 

[3] 3G TS 25.301 : "Radio Interface Protocol Architecture" 

[4] 3G TS 25.303: "Interlayer Procedures in Connected Mode" 

[5] 3G TS 25.322: "RLC Protocol Specification" 

[6] 3G TS 25.33 1 : "RRC Protocol Specification" 

[7] 3G TS 23. 121 : "Architectural Requirements for Release 1999" 

[8] IETF RFC 2507: "IP Header Compression" 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Access Stratum 

C-SAP Control Service Access Point 

IETF Internet Engineering Task Force 

L2 Layer 2 (data link layer) 

L3 Layer 3 (network layer) 

NAS Non Access Stratum 
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PDCP Packet Data Convergence Protocol 

PDU Protocol Data Unit 

PID Packet Identifier 

RB Radio Bearer 

RLC Radio Link Control 

RRC Radio Resource Control 

SDU Service Data Unit 

UE User Equipment 

UMTS Universal Mobile Telecommunications System 

UTRA UMTS Terrestrial Radio Access 

UTRAN UMTS Terrestrial Radio Access Network 



4 General 

4.1 Objective 

The present document describes the functionality of the UTRAN PDCP. The overall UTRAN logical architecture is 
defined in 3GPP TS 25.301 [3]. 

Network layer protocols are intended to be capable of operating over services derived from a wide variety of 
subnetworks and data links. UMTS supports several network layer protocols providing protocol transparency for the 
users of the service. At that point of view supported protocols are IPv4 and IPv6. Introduction of new network layer 
protocols to be transferred over UTRAN shall be possible without any changes to UTRAN protocols. Therefore, all 
functions related to transfer of packets from higher layers (PDCP-SDUs) shall be carried out in a transparent way by the 
UTRAN network entities. This is one of the requirements for UTRAN PDCP. 

Another requirement for the PDCP is to provide functions that help to improve channel efficiency. This requirement is 
fulfilled by the possibility to implement different kinds of optimisation methods. The currently known methods are 
standardised IETF header compression algorithms. 

Multiplexing of RBs onto the same RLC entity will be included in release 2000 but is not available in release "99. 
Therefor, in release "99 every RB, is connected to one PDCP entity and one PDCP entity is connected to one RLC 
entity. The PDCP entities are located in the PDCP sublayer. 

Every PDCP entity uses zero, one or several header compression algorithm types with certain parameters. Several 
PDCP entities may use the same algorithm type. The algorithm types and their parameters are negotiated by RRC and 
indicated to PDCP through the PDCP Control Service Access Point (PDCP-C-SAP). 

Since the adaptation of different network layer protocols to PDCP is implementation dependent, it is not defined in the 
present document. 



4.2 Overview on sublayer architecture 

Figure 1 shows the model of the PDCP within the UTRAN protocol architecture. Every PDCP-SAP uses exactly one 
PDCP entity. Each PDCP entity uses none, one or several header compression algorithm types 
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Radio Bearers 



C-SAP, 




Figure 1 : PDCP structure 



Functions 



Packet Data Convergence Protocol shall perform the following functions: 

Header compression and decompression of IP data streams (e.g., TCP/IP and RTP/UDP/IP headers)at the 
transmitting and receiving entity, respectively. The header compression method is specific to the particular 
network layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP. 

Transfer of user data. Transmission of user data means that PDCP receives PDCP-SDU from the NAS and 
forwards it to the RLC layer and vice versa. 

Buffering of transmitted PDCP SDUs and associating PDCP SDU Sequence Numbers to the transmitted and 
received PDCP SDUs to guarantee lossless SRNS relocation. 

Multiplexing of different RBs onto the same RLC entity. Multiplexing is not part of release "99 but will be 
included in release 2000. 



5.1 Header Compression 



The header compression method is specific for each network layer protocol type. The header compression algorithms 
and their parameters are negotiated by RRC for each PDCP entity and indicated to PDCP through the PDCP-C-SAP. 
Compressor and decompressor initiated signalling between peer PDCP entities during operation is carried out in the 
user plane. 

PDCP layer shall be able to support several header compression algorithms and it shall always be possible to extend the 
list of supported algorithms in the future. 
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The PDCP layer can have one or several PDCP entities. Each PDCP entity may use zero, one, or several header 
compression algorithms. It shall be possible to establish several header compression algorithms of different types 
related to one PDCP entity. Different PDCP entities may include header compression algorithms of the same type. 

Figure 1 shows an example how PDCP may be configured. 

5.1.1 Assignment of PID values 

PDCP shall be able to distinguish different types of header compression packets to handle them with a correct header 
compression algorithm and furthermore to indicate the type of the packet within a certain algorithm. This is realised by 
utilising the PID field in the PDU structure. PID values shall be assigned according to the dynamic PDCP entity specific 
allocation table which is configured during the configuration of the PDCP entity. The table is reconfigured every time 
the PDCP entity is reconfigured. 

The following table illustrates an example of the PID value allocation table when three arbitrary header compression 
methods (RFC2507, Methods A and B) are configured for one PDCP entity. 

Table 1 : Example of the PID value allocation table 



PID 
Value 


Optimisation method 


Paclcet type 





No header compression 


- 


1 


RFC2507 


Full header 


2 


RFC2507 


Compressed TCP 


3 


RFC2507 


Compressed TCP nondelta 


4 


RFC2507 


Compressed non TCP 


5 


RFC2507 


Context state 


6 


Method A 


Uncompressed TCP/IP 


7 


Method A 


Compressed TCP/IP 


8 


Method B 


Uncompressed IP/UDP/RTP 


9 


Method B 


Compressed IP/UDP/RTP 




Unassigned value 


- 



The assignment of the PID values follow the general rules listed below: 

PID value is reserved permanently for no compression. 

PID values are assigned in ascending order, starting from 1 . 

PID values are assigned independently to each PDCP entity. 

PID values are reassigned for the PDCP entity after renegotiation of the header compression algorithms. 

The list of negotiated (or re-negotiated) header compression entities shall be examined, starting from the first 
one in the list. The number of PID values to be assigned is specified in the subclause for this algorithm. 

If there are not enough unused PID values to be assigned to a header compression algorithm, the negotiated 
header compression entities using this algorithm shall be ignored without error notification. 

PID values that are used and are not defined invalidate the PDCP PDU. 

For a certain algorithm in a PDCP entity the assignment of PID values starts from (n+1) where n is the 
number of PID values already assigned to other algorithms. The assignment is done in the order the 
algorithms are negotiated by RRC. In the example given in table 1 RFC 2507 was the first, method A was 
the second and method B was the third algorithm in the PDCP Info information element exchanged between 
peer RRC entities. The PID follows this order. 

The used header compression algorithm and the packet type is unambiguously known by the basis of the PID value 
and shall apply to peer PDCP entities. While transferring data, the PID values are conveyed in the field of the PDCP 
header belonging to the PDCP -PDU. Any successfully negotiated algorithm may be used for header compression of 
an PDCP-SDU. 
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5.1 .2 TCP/IP and UDP/IP header compression (RFC2507) 

Detailed operation of the RFC2507 header compression is described in the chapter 3 of the IETF specification RFC 
2507 [8]. Furthermore the mechanisms related to error recovery and packet reordering are described in the chapters 10 
and 11 of the RFC 2507. These mechanisms shall be included in the functionality of the header compression supported 
by PDCP. 

5.1 .2.1 Assignment of PID values for RFC2507 

The following PID values shall be assigned to the RFC2507 header compression in the order presented in the table 
where n is the number of PID values already assigned to other algorithms 

Table 2: PID values assigned to RFC 2507 header compression algorithm 



PID value 


Optimisation method 


Packet type 


n+1 


RFC2507 


Full header 


n+2 


RFC2507 


Compressed TCP 


n+3 


RFC2507 


Compressed TCP non- 
delta 


n+4 


RFC2507 


Compressed non-TCP 


n+5 


RFC2507 


Context state 



5.2 



Multiplexing 



Multiplexing of different RBs onto the same RLC entity is not part of release "99 but will be included in release 2000. 
NOTE: A detailed description of the multiplexing function is to be added here 

5.3 PDCP-SDU buffering and numbering 

The PDCP-SDUs, which require reliable data transfer, shall be buffered and numbered in the PDCP layer. Numbering is 
carried out after header compression. The reception of an CPDCP-RELEASE.Req shall trigger the deletion of the buffer 
for the related PDCP entity. 

If lossless SRNS relocation is required, the PDCP entity shall buffer an PDCP-SDU until information of successful 
transmission of PDCP-PDU has been received from RLC. The confirmation is carried out using RLC-AM-DATA.Conf 
primitive from the RLC layer. 

For each radio bearer, an UL Send PDCP Sequence Number is associated with each sent PDCP-PDU in the UE and a 
DL Send PDCP Sequence Number is associated with each sent PDCP-PDU in the SRNC. For each radio bearer, an UL 
Receive PDCP Sequence Number is associated with each received PDCP-PDU in the SRNC and a DL Receive PDCP 
Sequence Number is associated with each received PDCP-PDU in the UE. 

When the PDCP entity is setup for the first time for the PDCP user the PDCP Sequence Numbers are initialised to zero. 
The corresponding values are incremented by one at each transmission and reception of a PDCP-PDU. The value of the 
PDCP sequence number ranges from to 255. 

For unacknowledged mode RLC data transfer, the PDCP entity shall delete an PDCP-SDU immediately after the 
corresponding PDCP-PDU has been delivered to RLC. 

NOTE: The technique of PDCP-SDU buffering is described only to provide a model for PDCP functions in case 
of lossless SRNS relocation. It shall not restrict implementation. 
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5.4 



Data Transfer 



5.4.1 Data transfer over acknowledged mode RLC 

If header compression is negotiated the PDCP entity shall perform header compression upon reception of a 
PDCP-DATA.Req. The PDCP-PDU is then forwarded in RLC-AM-DATA.Req to the RLC . The PDCP-SDU shall be 
stored into the buffer of the PDCP entity if lossless SRNS relocation is required. Buffered PDCP-SDU shall be deleted 
when the PDCP-SDU is confirmed to be transmitted by an RLC-AM-DATA.Conf. 

During operation, when the peer PDCP entity receives the PDCP-PDU in a RLC-AM-DATA.Ind primitive, the PDCP 
entity shall perform the header decompression (if negotiated) of PDCP-PDU to obtain the PDCP-SDU and forward the 
PDCP-SDU to the PDCP user with the PDCP-DATA.Ind. The following figure illustrates data transfer over 
acknowledged mode RLC. 



Originator 



PDCP user 



PDCP 



PDCP-DATA.req 
► 



RLC 



RLC-AM-DATA.req 
► 



RLC-AM-DATA.cnf 
< 



Receiver 



RLC 



Acknowledgement 
< 



PDCP 



RLC-AM-DATA.ind 
► 



PDCP user 



PDCP-DATA.Ind 
> 



Figure 2: PDCP data transfer over acknowledged mode RLC 

5.4.2 Data transfer over unacknowledged and transparent mode RLC 

If header compression is negotiated the PDCP entity shall perform header compression upon reception of a 
PDCP-DATA.Req. The PDCP-PDU is then forwarded in RLC-UM-DATA.Req or RLC-Tr-DATA.Req to the RLC 
layer. The PDCP-SDU shall be deleted immediately after the data has been delivered to the RLC layer. 

When the peer PDCP entity receives the PDCP-PDU in the RLC-UM-DATA.Ind or RLC-Tr-DATA.Ind primitive, the 
PDCP entity shall perform the header decompression (if negotiated) of PDCP-PDU to obtain the PDCP-SDU and 
forward the PDCP-SDU to the PDCP user with the PDCP-DATA.Ind. The following figure illustrates data transfer over 
unacknowledged and transparent mode RLC. 



Originator 



PDCP user 



PDCP 



PDCP-DATA.req 
► 



RLC 



RLC-UM-DATA.req/ 



RLC-Tr-DATA.req 



Receiver 



RLC 



PDCP 



PDCP user 



RLC-UM-DATA.Ind, 
=iLC-Tr-DATA.Ina PDCP-DATA.Ind 



Figure 3: PDCP data transfer over unacknowledged or transparent mode RLC 
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5.5 SRNS Relocation 

The PDCP layer shall carry out following functions during lossless SRNS relocation: 

transmission of all PDCP-SDUs to target SRNC that have not been received correctly, 

forwarding of PDCP-SDUs and associated sequence numbering from old SRNC to target SRNC; 

transfer of next expected PDCP SDU sequence number from UE to target SRNC and vice versa and 

either reset of PDCP entities (when negotiated for the entity). 

or forwarding of internal protocol information from source to target SRNC (when negotiated for the entity). 

These procedures are started by CPDCP-RELOC.Req primitive from the RRC layer. For each radio bearer, the Receive 
PDCP Sequence Number of the next PDCP SDU expected to be received is transferred from the source to target SRNC. 
For each radio bearer the source SRNC forwards to the target SRNC the downlink PDCP-SDUs stored in its buffer. 
Source SRNC provides the Send PDCP SDU Sequence Number of the PDCP-SDU which is first in the buffer to the 
target SRNC. 

The target SRNC shall send to the UE the next expected UL Receive PDCP Sequence Number., The UE shall send to 
the target SRNC the DL Receive PDCP Sequence Number of the next expected PDCP SDU.. The successfully 
transmitted PDCP-SDUs are thus confirmed. 

During the relocation the PDCP Sequence Numbers are either reset to zero (if PDCP reset is negotiated by RRC for the 
PDCP entity in case of SRNS relocation) or the PDCP contexts are transferred from the source to the target SRNC and 
the PDCP Sequence Numbers continue from their previous value (if PDCP reset is not negotiated by RRC for the PDCP 
entity in case of SRNS relocation). 

The reset of all compression entities shall be made during SRNS relocation, when negotiated by RRC in the 
Reconfiguration reset parameter for that PDCP entity. Negotiated compression parameters remain valid during reset, 
but all state information is initialised, e.g. header compression contexts. Therefore, in header compression case, the first 
'compressed' packet is a full header. Otherwise, when RRC negotiated in the Reconfiguration reset parameter not to 
reset the PDCP entity, internal protocol information, i.e. states and header compression contexts, shall be forwarded 
from source SRNC to target SRNC in the network side. In header compression case, the header compression can then 
continue from the status it had directly before SRNS relocation. 

In the case where lossless SRNS relocation is not required, the PDCP layer shall carry out following functions: 

- reset of compression entities (if indicated by RRC in the Reconfiguration reset parameter). 

if Reconfiguration reset parameter indicates not to reset the PDCP entity (in RRC signalling), internal protocol 
information, i.e. states and header compression contexts, shall be forwarded from source SRNC to target SRNC. 

6 Services 

6.1 Services provided to upper layers 

The following services are provided by PDCP to upper layers: 

- PDCP-SDU delivering. 

6.2 Services provided to RRC layer 

The following services are provided by PDCP to RRC layer: 
The configuration of PDCP. 
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6.3 Services expected from RLC layer 

For a detailed description of the following functions see [5]. 
Data transfer in acknowledged mode, 
Data transfer in unacknowledged mode, 
Data transfer in transparent mode. 
Segmentation and reassembly, 
In-Sequence delivery. 



7 Elements for layer-to-layer communication 

7.1 Primitives between PDCP and upper layers 

The primitives between PDCP and upper layers are shown in Table 3. 

Table 3: Primitives between PDCP and upper layers 



Generic Name 


Parameter 


Req. 


Ind. 


Resp. 


Conf. 


PDCP-DATA 


Data 


Data 


Not Defined 


Not Defined 


CPDCP-CONFIG 


PDCP-lnfo, RLC-SAP 


Not defined 


Not Defined 


Not Defined 


CPDCP-RELEASE 


FFS 


Not defined 


Not Defined 


Not Defined 












CPDCP-RELOC 


FFS 


FFS 


Not Defined 


Not Defined 



Each Primitive is defined as follows: 

a) PDCP-DATA-Req./Ind. 

PDCP-DATA-Req is used by higher user-plane protocol layers to request a transmission of higher layer PDU. 
PDCP-DATA-Ind is used to deliver PDCP SDU that has been received to upper user plane protocol layers. 

b) CPDCP-CONFIG-Req. 

CPDCP-CONFIG Req is used to configure and - in case of already existing PDCP entity - to reconfigure a 
PDCP entity and to assign it to the radio bearer associated with that entity. 

c) PDCP-RELEASE-Req. 

CPDCP-RELEASE-Req is used by RRC to release a PDCP entity. 

d) CPDCP- RELOC-Req./Ind. 
See chapter 5.5. 

The following parameters are used in the primitives: 

1) PDCP info 

Contains the parameters for each of the header compression algorithms configured to be used by one PDCP 
entity. 

2) RLC-SAP 

The RLC-SAP (Tr/Um/Am) used by PDCP entity when communicating with RLC sublayer. 
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8 



Elements for peer-to-peer communication 



8.1 



Protocol data units 



Currently two different protocol data unit formats are defined in PDCP. A configuration parameter provided by RRC 
with CPDCP-CONFIG primitive for every PDCP entity selects whether PDCP shall introduce a PDCP PDU header or 
not. 



8.2 



Formats 



8.2.1 PDCP-No-Header PDU 

The PDCP-No-Header PDU does not introduce any overhead to the PDCP-SDU. 
The format of the PDCP-No-Header-PDU is shown in Table 4. 

Table 4: PDCP-No-Header PDU 



Bit 


8|7|6|5|4|3|2|1 


Octi 


Data segment 


... 


N 



8.2.2 PDCP Data PDU 

The data PDU is used to convey a payload unit containing a PDCP-SDU, header compression related control signalling 
or data that has been obtained from PDCP-SDU after header compression. The format of the PDCP-Data-PDU is shown 
in Table 5. 

Table 5: PDCP-Data-PDU format 



Bit 


8 1 7 1 6 


5 1 4 1 3 


2 


1 


Octi 


PDU type 


PID 1 


... 


Data segment 


N 



8.3 



Parameters 



8.3.1 PDCP-No-Header-PDU 

The PDCP-No-Header-PDU does not contain any parameters. 

8.3.2 PDCP-data-PDU 

The PDCP-data-PDU parameters are defined as follows: 

- PDU type 

000 PID field used for header compression information (PDCP-PDU format described in table 5) 

001 Not defined in release '99 



111 



Not defined in release '99 
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- PID: 

No header compression 

1-31 Dynamically negotiated header compression identifier 

PID field value defines used header compression type and packet type. One compression algorithm may reserve a 
certain amount of values from PID field value space for different packet types. Receiving PDCP makes reverse 
operation (e.g. header decompression) according to PID field value. There is not fixed relation between PID field 
value and used optimisation / packet type, but PID field values are defined dynamically at the PDCP parameter 
negotiation. 



Handling of unknown, unforeseen and erroneous 
protocol data 
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